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A  KNOWLEDGE-BASED  SYSTEM  FOR  LP  MODELING 

Daniel  R.  Dolk 
Naval  Postgraduate  School 

1 .  INTRODUCTION 

The  focus  of  this  paper  Is  on  linear  programming  (LP)  software  In  the 
context  of  model  management  and  decision  support.  As  a  result,  we  will  not 
be  Interested  In  the  algorithmic  properties  of  LP  or  math  programming  (MP) 
codes,  but  rather  their  applicability  to  more  generalized  modeling  environments 
wherein  models  can  be  linked  or  decomposed  In  a  manner  which  frees  the  user 
from  having  to  know  the  Internal  representation  which  the  algorithms  require. 

In  particular,  we  will  look  at  the  objectives  and  functions  of  a  generalized 
model  management  system  and  how  these  require  a  knowledge-based  modeling 
capability.  We  will  then  describe  a  partial  Implementation  of  a  knowledge- 
based  modeling  system  for  LP  models  called  the  Generalized  experimental  Math 
Programing  system  (GXMP). 

T 

2.  LP  ANO  MODEL  MANAGEMENT 


Most,  If  not  all,  LP  software  has  operated  on  the  assumption  that  users  know 
enough  about  their  model  to  select  the  correct  package  to  use  to  obtain  a 
computer  solution.  In  the  decision  support  environment,  the  user,  In  fact. 


may  not  be  aware  of  what  models  are  needed  or  available  to  solve  the  problem 


at  hand.  In  this  case.  It  becomes  the  task  of  the  model  management  system  to  1° 

orchestrate  the  appropriate  models  and  data  to  solve  a  user-described  problem 
(Figure  1). 
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Figure  1:  Role  of  Model  Management  In  Decision  Support 
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In  order  for  an  MMS  to  function  In  this  capacity,  it  clearly  requires 
a  knowledge-based  capability  for  representing  knowledge  about  models.  The 
following  kinds  of  knowledge  should  be  contained  In  the  MMS,  for  example: 

1.  Which  situations  particular  models  are  applicable  to; 

2.  Model  integrity  statements; 

3.  Information  required  to  instantiate  a  model; 

4.  Which  solution  algorithm(s)  to  employ  to  solve  a  model; 

5.  How  to  link  models  to  other  models; 

6.  How  to  decompose  models  Into  submodels; 

7.  Interpretation  of  model  results. 

In  addition  to  knowledge  representation  and  storage,  an  MMS  must  also 
have  one  or  more  generalized  problem-solving  or  inferenclng  capabilities  for 
manipulating  the  knowledge.  This  “reasoning"  capability  should  encompass 
heuristic  as  well  as  deterministic  reasoning  so  that,  for  example,  the  MMS 
can  pattern-match  user-supplied  problem  descriptions  with  available  model  and 
data  Instances.  The  first  order  predicate  calculus  has  been  suggested  as  one 
means  of  representation  (Bonczek  et  al,  1981)  which  Is  well-suited  for  deter¬ 
ministic  kinds  of  Inferences.  Semantic  networks  have  been  considered  to  support 
more  heuristic  kinds  of  reasoning  within  a  modeling  environment  (Elan  et  al, 
1980).  The  GXMP  system  Is  based  on  the  concept  of  knowledge  abstractions,  or 
In  the  case  of  modeling,  model  abstractions  (Dolk,  1982;  Konsynski  and  Dolk, 
1982),  a  knowledge  representation  scheme  which  attempts  to  combine  the  strengths 
of  deterministic  and  heuristic  Inferenclng  (Dolk,  1982). 

A  model  abstraction  consists  of  three  parts:  data  objects,  procedures 
acting  upon  those  objects,  and  assertions  or  facts  (knowledge)  concerning  the 
relationships  between  data  objects  and  procedures  (Figure  2).  For  MP  models, 
data  objects  correspond  to  constraint  equations  and  model  parameters,  procedures 


(Ex:  Constraint  Equations, 

Index  Sets) 

PROCEDURES 

(Ex:  Add-Constraint-Model , 

Modify- Index-Set- Value, 

Linear  (Equation)) 

ASSERTIONS 

(Ex:  Linear  (Constraint), 

Linear  (Obj-Func)) 

Figure  2.  Model  Abstraction  Structure 

are  operators  which  act  upon  the  data  objects  (AOD-CONSTRA1NT-TO-MODEL,  e.g.), 
and  assertions  specify  Integrity  conditions  ("constraints  must  be  linear  In  an 
LP  model e.g.). 

A  modeling  system  with  a  knowledge- based  capability  alters  the  traditional 
view  of  modeling  software  (Figure  3).  Typically,  math  programming  software  has 
been  algorithmically  oriented  wherein  the  Input  data  are  prepared  by  the  user- 
modeler  and  fed  Into  a  "black  box"  program  which  applies  the  algorithm  to  supply 
the  results.  Knowledge  about  the  models  Is  supplied  externally  by  the  modeler 
In  preparing  the  Input  and  Internally  by  the  programmer  in  specifying  the 
algorithm.  In  neither  case  is  this  knowledge  accessible  to  other  users  who  see 
only  the  Input  and  the  "black  box."  In  the  knowledge-based  modeling  system, 
however,  this  structure  Is  expanded  to  abstract  the  knowledge  pertinent  to  a 
model  Into  a  separate  data  component  of  the  system.  Furthermore,  the  algorithms 


(a)  Traditional  Modeling  Software  System 
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(b)  Knowledge-Based  Modeling  System 


Figure  3.  Difference  Between  Traditional  and  Knowledge- Based 
Modeling  Systems 


are  stored  as  data  in  a  procedure  library  to  be  used  by  the  reasoning  module  in 
constructing  a  model  program  to  solve  the  problem  described  by  the  user.  For 
those  familiar  with  rule-based  expert  systems,  the  knowledge  base  would  consist 
of  rules  expressed  In  a  IF  antecedents (s}>  THEN  <consequent(s)>  fashion 
and  the  reasoning  program  would  correspond  to  a  rule  Interpreter  (Duda  and 
Gaschnlg,  1981). 


3.  THE  GXMP  SYSTEM 


The  remainder  of  this  paper  describes  a  "first  pass"  Implementation 
of  a  knowledge-based  model  management  system  for  LP  models  called  GXMP.  Much 
of  the  effort  to  date  on  GXMP  has  been  involved  with  establishing  a  suitably 
powerful  modeling  language  for  expressing  MP  models.  As  a  result,  the  knowledge- 
based  capabilities  of  the  system  are  still  very  limited.  Development  phases 
for  Incorporating  these  features  into  GXMP  are  presented  in  the  concluding 
section. 

Figure  4  shows  the  salient  Implementation  features  of  GXMP.  The  system 
is  written  in  FORTRAN  on  a  Vax-1 1/780  using  the  XMP  linear  programming  library 
(Marsten,  1980)  and  the  ADBMS  database  management  system  (Hershey  and  Messink, 
1975).  The  overall  goal  of  the  GXMP  system  Is  to  serve  as  a  user-friendly 
virtual  machine  for  LP  (and  eventually  MP)  algorithms.  Thus,  although  the  XMP 
library  was  chosen  as  the  source  of  the  simplex  algorithm,  there  is  no  restric¬ 
tion  on  using  other  algorithms  providing  they  accept  input  In  matrix  form. 

The  components  of  GXMP  are  shown  in  Figure  5.  There  are  five  different 
database  types: 

1.  The  directory  catalogs  all  Instances  of  models,  data  objects,  abstrac¬ 
tions,  and  databases  currently  In  the  system; 

2.  The  abstraction  database  stores  model  abstractions  and  serves  as  the 
knowledge  base  of  the  system; 

3.  The  procedure  database  stores  the  subroutines  from  the  XMP  library 
Including  the  source  code; 

4.  The  equation  database  stores  an  Instance  of  a  model  expressed  In  the 
GXMP  modeling  language; 

5.  The  parameter  database  stores  the  associated  numerical  parameters  of  a 
model  instance  (coefficient  and  right-hand-side  values,  e.g.). 

Interface  with  the  user  occurs  at  two  levels:  a  menu  dialog  for  selecting  the 

system  functions  to  be  performed  and  a  modeling  language  for  expressing  LP 
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Model  Management  System  for  LP 
FORTRAN 

XMP  Library  (Marsten,  1980) 

ADBMS  (Hershey  and  Messink,  1975) 
Knowledge-Based  (model  abstractions) 
User-Friendly  Virtual  Machine  for  LP  Algorithms 


Figure  4.  Features  of  6XMP  Implementation 


OATABASES 

Directory  (catalog) 

Abstraction  (knowledge  base) 

Procedure  (XMP  library) 

Equation  (expressed  in  modeling  language) 
Parameter  (coefs,  rhs,  etc.) 

MENU  DIALOG 

MODELING  LANGUAGE 

SOLUTION  REPORTER 

Figure  5.  Components  of  the  GXMP  System 


models  In  a  mathematical  fashion.  The  menu  dialog  accommodates  the  "naive” 
user  while  the  modeling  language  is  geared  toward  the  modeler.  The  solution 
reporter  generates  LP  solutions  In  terms  of  the  variables  which  the  user 
specifies  during  model  creation.  Examples  of  these  various  aspects  of  the  system 
are  shown  In  the  sample  problem  of  the  next  section. 
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The  GXMP  modeling  language  is  designed  to  allow  modelers  to  represent 


expressions  in  qua si -mathematical  notation.  It  is  somewhat  similar  to  FORTRAN 
and  contains  several  key  features: 

1.  User-supplied  variable  names  in  place  of  mathematical  variables  (self- 
documenting): 


Math-Var 


Description 


GXMP- Name 


shipment  from  city  i 
to  city  j 

demand  from  city  j 


SHIPMENT  (i,j) 


DEMAND  (j) 


2.  Use  of  inequality  signs  for  expressing  constraints. 

3.  MIN,  MAX,  SUM  operators. 

4.  Use  of  mathematical  Indexes  in  equations. 

5.  FOR  clause  for  specifying  conditions  on  indexes  and  Instantiating 
indexes. 

n 

Ex:  To  express  T  X*.  «  D.  for  j»l,...,n;  j<>1 
i«l  J 

SIW(  1 ) [SHIPMENT ( 1 ) ]  *  DEMAND(j) 

FOR  i  OVER  CITY,  j  OVER  CITY,  1<>J  $ 

6.  Use  of  index  expressions 

Ex:  CONSUMPTION(p.t)  +  INVENTORY (p,t)  - 
INVENTORY(p.t-l)  «  SUPPLY(p.t) 

FOR  p  OVER  COMMODITY,  t  OVER  PERIOD  S 

Several  other  syntactical  features  and  restrictions  should  be  mentioned 

1.  All  indexes  must  be  expressed  in  lower  case  and  cannot  exceed  four 
characters  in  length.  Indexes  "max"  and  "min"  are  reserved  names 
(see  4.  below). 

2.  Simple  index  expressions  of  the  form  <1ndex>  <"♦"  or  "-*> 
cinteger  or  index>  are  allowed,  e.g.:  X(1-l,t+l). 

3.  Indexes  must  be  used  consistently  over  all  equations  and  each  Index 
appearing  in  an  equation  must  be  identified  in  that  equation.  The 
first  restriction  states  that  index  i,  for  example,  must  be  the  same 


in  each  equation  in  which  it  appears.  Furthermore,  different  index 
names  cannot  be  used  in  different  equations  to  represent  the  same 
index  (unless  the  index  forms  a  link).  The  second  restriction 
requires  identifying  an  index  whenever  it  appears.  This  leads  to  a 
certain  amount  of  redundant  specification  but  results  in  fully 
documented  equations. 


Each  instance  of  SUM  must  be  followed  by  one  or  more  indexes  enclosed 
in  parentheses  and  the  summand  enclosed  in  square  brackets,  e.g.: 


is  expressed  as: 


SUM  (i,j)[X(i ,j)] 


Conditions  on  indexes  can  be  expressed  in  conjunction  with  index 
identification,  thus  we  can  express: 

0  <=  X(i,j)  <=*  DEMAND (i  ,j)  fOR  i  OVER  CITY, 

j  OVER  CITY,  i  <>  j  $ 


to  indicate  that  the  constraint  holds  for  all  i , j  except  i= j. 
("<>"  indicates  the  "not  equal"  operator.)  The  reserved  words  "max" 
and  "min"  can  be  used  to  refer  to  the  highest  and  lowest  cardinal 
values  of  an  index  respectively,  thus 


can  be  expressed  as: 

SUM(i ,j)[X(i ,j)]  FOR  i<max,  j<max,  i  OVER... 

All  decision  variables  must  be  grouped  onto  one  side  of  a  constraint. 
Thus  if  C  and  F  are  decision  variables: 

C(p,t)  +  F(p,t)  3  S(p,t)  +  F(p,t-1)  FOR  ... 

will  not  be  translated  properly  and  should  be  rewritten  as: 

C(p,t)  +  F(p,t)  -  F(p,t-1)  *  S(p,t)  FOR  ... 

Each  unique  combination  of  decision  variable  and  indexes  may  appear 
only  once  in  a  particular  equation.  Thus  the  following  objective 
function  with  decision  variable  DV: 

MAX(SUM(i ,j)[REV(1 ,j)*DV(i ,j)-EXPNS(i ,j)*DV(i ,j)]) . . 

will  not  be  translated  properly  and  should  be  rewritten  as: 

MAX(SUM(i ,j)[(REV{i ,j)-EXPNS(i,j))*DV(i ,j)]). . 
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Note  this  restriction  does  not  obviate  a  decision  variable  from 
appearing  more  than  once  in  an  equation  as  long  as  it  has  different 
index  expressions  each  time  (see  sample  in  6.  above). 

8.  Only  constraint  and  objective  function  expressions  are  allowed.  No 
intermediate  expressions  may  be  inserted.  This  means  that  although  it 
would  be  convenient  to  write  the  objective  function  above  as: 

UNIT-PROFIT(i.j)  =  REV(i.j)  -  EXPNS(i.j) 

PROFIT  *  SUM(i , j ) [UNIT-PROFIT ( 1 ,j)*DV(i ,j)j. . . 

MAX (PROFIT) 

it  is  not  currently  permitted  in  the  GXMP. 

Only  the  last  point  is  a  serious  restriction  of  the  language  in  any  sense,  yet 
it  does  not  pose  any  conceptual  difficulty  involving  implementation.  It  was 
Imposed  primarily  to  expedite  the  development  time  of  a  "first  pass"  version 
of  the  system. 

An  example  of  the  language  applied  to  a  sample  problem  is  presented  in 
the  next  section. 

4.  A  GXMP  EXAMPLE 

This  section  presents  a  simple  problem  to  show  how  the  GXMP  operates 
in  creating  and  solving  a  model.  The  model  we  are  going  to  use  is  the  school 
rezoning  problem  discussed  in  Hillier  and  Lieberman  (1974,  pp.  196-201).  The 
gist  of  the  problem  is  to  minimize  the  distance  students  need  tc  be  bused  to 
school  while  maintaining  a  specified  racial  balance  in  each  school.  A  mathe¬ 
matical  representation  is  displayed  in  Figure  6. 

GXMP  recognizes  three  different  kinds  of  parameters: 

1.  index  sets  (i  and  j  in  this  model); 

2.  decision  variables  (X); 

3.  numerical  parameters  (B,  W,  S,  T); 

Index  sets  correspond  to  the  indexes  in  the  mathematical  representation  but 
their  values  in  the  GXMP  are  always  character  quantities  rather  than  numerical 


Variable  Description 


No.  of  students  in  tract  i  assigned  to  school  j 

Di stance  from  tract  i  to  school  j 

No.  of  black  students  in  tract  i 

No.  of  white  students  in  tract  i 

Capacity  of  school  j 

Parameter  such  that  .5-T  <_  racial  balance  <_  .5+T 


min  l  l 

*  0 

St  I  X. j  *  B.  +  W. 


for  1*1,...  *10;  j*  1,2,3 


for  1*1 . 10;  j*l,2,3 


(all  students  are  assigned  to  schools) 


\  Xij  -  S3 


for  1*1,. ..,10;  j*l,2,3 


(school  capacity  not  exceeded) 


l  (.5-T-Wi/(Bi+Wi))X1j  <  0  for  1  *  1,  —  .10;  j*l,2,3 
l  (.5-T-B./(Bi+W1))X1j  <  0  for  i  *  1 ,  —  *10;  j*1.2, 3 


(racial  balance) 


xiji° 

(nonnegativity) 


for  1*1,...,  10;  j*  1,2,3 


Figure  6.  Mathematical  Description  of  School  Rezoning 
Model 


quantities  as  in  the  mathematical  case.  This  significantly  Increases  the 
documentation  value  of  the  system.  Decision  variables  are  the  quantities  being 
solved  for  by  the  simplex  method.  Numerical  parameters  are  those  quantities 
with  numerical  values,  usually  coefficients  or  right-hand-sides  in  the 
equations. 

When  entering  parameters,  always  enter  the  index  sets  first  since  subse¬ 
quent  parameters  will  depend  upon  them.  This  is  done  in  our  example  by  speci¬ 
fying  TRACT  for  index  i  and  SCHOOL  for  index  j.  For  each  parameter  entered, 
the  system  will  prompt  the  user  for  parameter  type,  data  type  (not  prompted 
for  index  sets  and  decision  variables),  documentation,  indexes  (if  any)  that 
the  parameter  depends  upon,  and  data  values  to  be  entered  at  this  time  (if  any). 

When  entering  parameters  which  are  indexed,  include  the  indexes  as  part 
of  the  name  selected  ("DISTANCE(i,j)"  for  "X"  for  example).  The  indexes  must 
be  specified  in  lower  case  and  cannot  exceed  four  characters  in  length.  They 
must  also  be  used  consistently  across  parameters  and  equations,  i.e.  "1"  cannot 
refer  to  TRACT  in  one  case  and  SCHOOL  in  another.  Neither  can  “i"  refer  to 
TRACT  in  one  case  and  "j"  refer  to  TRACT  in  another  (unless  TRACT  forms  the 
basis  of  a  network  problem  which  is  not  the  case  here).  The  best  way  to  avoid 
confusion  is  to  construct  a  table  that  correlates  the  variables  in  the  mathe¬ 
matical  description  with  their  GXMP  counterparts  (Figure  7).  Once  the  desired 
parameters  have  been  added  to  the  model,  a  listing  of  those  parameters  can  be 
obtained  (Figure  8). 

The  next  step  In  specifying  the  model  is  to  enter  the  objective  function 
and  the  constraints  using  the  modeling  language  described  in  the  previous 
section.  The  important  rules  to  remember  when  entering  equations  are: 

1.  No  Intermediate  expressions  are  allowed,  thus  there  will  be  only  one 

objective  function  expression; 
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$ 
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Model  Variable  Parameter  Type 

GXMP  Name 

1 

Index  set 

TRACT 

j 

Index  set 

SCHOOL 

*u 

Decision  var 

STUDENTS (1,j) 

•u 

Parameter 

DISTANCED  ,j ) 

B1 

Parameter 

BLACKS(I) 

“l 

Parameter 

WHITES(I) 

Parameter 

SCHOOL-CAPAC(j) 

T 

Parameter 

THETA 

Figure  7. 

GXMP  Parameter  Names  for  School  Rezoning  Model 
Variables 

2.  All  parameters  appearing  In  an  equation  must  be  defined  In  the 
parameter  database  prior  to  equation  entry; 


3.  Each  separate  Index  appearing  in  an  equation  must  be  Instantiated 
In  the  FOR  clause  and,  like  parameter  entry.  Indexes  must  be  used 
consistently  across  equations; 


4.  Suonation  Is  expressed  by 

SUM(1 ndexl , 1 ndex2 summand] ; 

5.  Always  end  each  equation  with  a 

Equations  are  clas^i'  as  either  constraints  (CONSTR)  or  objective  function 
(OBJFCN)  and  assignee  number  as  well.  If  the  user  does  not  specify 

an  Id  nunber  when  it  ring  an  equation,  the  system  will  assign  one  automati¬ 
cally.  Once  the  equations  have  been  entered,  they  can  be  displayed  In  a 
manner  similar  to  that  of  the  parameters  (Figure  9). 


•  • .  a  . ..  «* 


♦Type  <CR>  for  Previous  Menu 

1  for  Equation  Operations 

2  for  Parameter  Operations 

3  to  Solve  Model 


♦Type  <CR>  for 


Previous  Menu 
Add  Parameter(s) 

Delete  Parameter (s) 

Modify  Parameter^ ) 

Specify  Values  for  Parameters 
Link  Parameters 
Display  Parameters  In  Model 
Display  Parameter  Values 


♦Parameter  name  (20  chars  max) 

(If  adding.  Include  Indexes  if  any,  eg:  DEMAND(l.j) 
(Type  ALL  for  all.  Hit  <CR>  to  end  parameter  entry): 


Parameter-Name 

Type 

Type 

Description 

BLACKS (1) 

1:  TRACT 

PA 

R 

Black  students  In 
tract  1 

DISTANCE(1,j) 

1 :  TRACT 

PA 

R 

Distance  from  tract  1 
to  school  j 

j:  SCHOOL 

SCHOOL 

IS 

C 

Schools 

SCHOOL-CAPAC(j) 

PA 

R 

School  j  student  capacity 

j:  SCHOOL 

STUDENTS(IJ) 

1:  TRACT 

DV 

R 

Students  In  tract  1 
assigned  to  school  j 

J:  SCHOOL 

THETA 

PA 

R 

Parametric  quantity 

TRACT 

IS 

C 

School  tracts 

WHITES(I) 

PA 

R 

White  students  In  tract  1 

1:  TRACT 

figure  8.  GXMP  Session  Displaying  School  Rezoning 
Model  Parameters 


♦Type  <CR>  for  Previous  Menu 

1  for  Equation  Operations 

2  for  Parameter  Operations 

3  to  Solve  Model 

*1 

♦Type  <CR>  for  Previous  Menu 

1  to  Add  Equations )  to  Model 

2  to  Delete  Equatlon(s)  from  Model 

3  to  Renumber  Equatlon(s)  In  Model 

4  to  Display  Equatlon(s)  In  Model 

5  to  List  Variables  In  Equations 

6  to  Compile  Equations 
*4 

♦Type  <CR>  to  Return  to  Previous  Menu 

1  If  Equation  Is  a  Constraint 

2  If  Equation  Is  Objective  Function 

*2 

♦Type  equation  Id  (0  for  all): 

#0 

OBJFCN-Id  Equation 

10  MIN (SUM (1 ,j)lDISTANCE(1 ,J)*STUDENTS(1 ,j)]) 

FOR  1  OVER  TRACT,  j  OVER  SCHOOL  $ 

1  OBJFCN  equations  In  model 

♦Type  <CR>  to  Return  to  Previous  Menu 

1  if  Equation  Is  a  Constraint 

2  If  Equation  Is  Objective  Function 

*1 

♦Type  equation  Id  (0  for  all): 

#0 

CONSTR-Id  Equation 

10  SUM(j  )£STU0ENTS ( 1 » j ) J  *  BLACKStD  +  WHITES(I) 

FOR  1  OVER  TRACT,  j  OVER  SCHOOL  $ 

20  SUMlUESTUDENTSlI.j)]  -  SCHOOL-CAPAC(j) 

FOR  1  OVER  TRACT,  j  OVER  SCHOOL  $ 

30  SUM(1)£(.5  -  THETA  -  WHITESO )/(WHITES(i ) 

BLACKS  Cl  )))*STU0ENTS(1,j)]<?  0. 

FOR  1  OVER  TRACT,  j  OVER  SCHOOL  $ 

40  SUMCHE1.5  -  THETA  -  BUCKS (1 )/ (WHITES (1 ) 

BUCKS(.1)))*STUDENTS(1  ,j)]  <•  0. 

FOR  1  OVER  TRACT,  j  OVER  SCHOOL  $ 

50  STUDENTS (1  ,j)*  0. 

FOR  1  OVER  TRACT,  j  OVER  SCHOOL  $ 

5  CONSTR  equations  In  model 


Figure  9.  GXMP  Session  Displaying  School  Rezoning 
Model  Equations 
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The  primary  strength  of  the  GXMP  modeling  language  is  the  indexing 
capability  which  allows  equations  to  be  specified  symbolically  and  concisely. 

Note  that  each  constraint  equation  in  the  school  rezoning  problem  in  Figure  6 
actually  represents  multiple  constraint  Instances.  Constraint  10,  for  example, 
symbolizes  i  constraint  Instances.  This  economy  of  expression  due  to  the  mathe¬ 
matical  nature  of  the  modeling  language  allows  users  to  represent  large  models 
with  very  few  equations. 

Furthermore,  the  language  is  robust  in  that  it  enforces  a  high  degree 
of  Independence  between  the  equations  and  the  data.  It  is  sufficient  to  observe 
that  tracts  and  schools  could  be  added  or  dropped  from  the  parameter  database 
for  the  school  rezoning  problem  without  having  to  make  a  single  change  to  the 
equations  in  Figure  9.  Similarly,  equations  could  be  added  or  deleted  without 
altering  the  parameter  data  values.  This  would  not  be  the  case  if  a  language 
required  that  each  constraint  be  enumerated  explicitly.  Clearly  there  is  a 
connection  between  model  Independence  and  the  power  of  a  modeling  language. 

Once  a  model  has  been  fully  specified  (parameters,  parameter  values, 
and  equations).  It  Is  ready  to  be  solved.  The  model  solution  process  takes 
place  as  shown  in  Figure  10.  The  appropriate  model  abstraction  Instance  for 
the  model  is  located  and  a  SOLVE  predicate  located  within  the  abstraction.  The 
SOLVE  predicate  lists  which  XMP  routines  need  to  be  Invoked  and  the  order  of 
invocation  in  order  to  effect  a  solution  for  the  model.  In  a  batch  environment, 
a  job  stream  is  established  consisting  of  JCL  commands,  the  appropriate  XMP 
routines  retrieved  from  the  procedure  library,  and  parameter  data  and  equations 
retrieved  from  the  parameter  and  equation  databases.  The  job  stream  Is  submitted 
as  a  batch  job  whose  result  file  Is  then  processed  Interactively  in  a  later 
session.  In  a  totally  Interactive  setting,  the  XMP  routines  are  executed 
dynamically  and  the  solution  generated  online.  The  obvious  disadvantage  of  the 


wwy mmm mm gmiw  wa-a a 


MP  PROBLEM-SOLVER 


Figure  10.  The  SXMP  Model  Solution  Process  for  Batch  Jobs 


latter  approach  Is  that  online  processing  may  be  too  tlme-consunlng  for  all 
but  small  scale  LP  problems.  Because  our  example  Is  small,  the  Interactive 
approach  Is  used  In  this  case. 

Once  the  model  has  been  solyed  yta  the  XMP  routines,  the  solution 
reporter  Is  Invoked  to  report  the  results  (Figure  11).  The  reporting  of 
linear  programing  results  has  been  a  long-standing  problem  especially  with 
large  models  having  many  variables.  At  the  root  of  the  problem  Is  the  naming 
convention  that  systems  Impose  on  the  unfortunate  user  which  often  results  In 
confusion  as  to  which  variable  Is  which  In  the  report.  Names  like  "Variable  1" 
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*  *  *  *  *  GXMP  SOLUTION  REPORTER  *  *  *  *  * 


Model  Type  :  LP-EON 
Model  Instance:  SCHOOL-REZONING 


Number  of  Linear  constraints  19 

Number  of  Variables  (Incl.  slacks  &  artificials):  49 

Variable  Identification  Value 


STU0ENTS(TRACT1 .JEFFERSON) 
STUDENTS  TRACT2 .JEFFERSON ) 
STUOENTS ( TRACT3 .JEFFERSON ) 
STUDENTS (TRACT4 .WASHINGTON ) 
STUDENTS (TRACT5 .WASHINGTON) 
STUDENTS ( TRACTS .WASHINGTON ) 
STUDENTS (TRACT7 .JEFFERSON ) 
STUDENTS ( TRACT7 .WASHINGTON ) 
STUDENTS ( TRACT8 .HAMILTON ) 
STUDENTS { TRACT9 .WASHINGTON) 
STUDENTS (TRACT9 .HAMILTON) 
STUDENTS(TRACT10 .HAMILTON ) 


0. 45000000D+03 
0 . 40000000D+03 
0.50000000D+03 
0.50000000D+03 
0.400000000+03 
0.45 000000D+03 
0.150000000+03 
0.30000000D+03 
0.500000000+03 
0 . 50000000D+02 
0.350000000+03 
0.45000000D+03 


♦"^Remainder  of  variables  are  slacks/artificials*** 


Constraint  for  Which  Variable  Is  Basic 


Value 


SCHOOL-CAPAC(HAMILTON) 
WHITE-RATIO{ JEFFERSON) 
WHITE-RATIO (WASHINGTON) 
WHITE-RATIO (HAMILTON) 
TRACT-ASSIGNMENT (TRACTS ) 
TRACT-ASSIGNMENT (TRACT9 
TRACT-ASSIGNMENT (TRACT8 ) 

Value  of  Objective  Function: 


0.30000000D+03 
0.55583337D+03 
0.91 6681 44D+00, 
0.410750020+03 
0.891666890+02 
0.740083360+03 
0.1 4825001 D+03 

-0.496500000+04 


Constraint 


Dual  Variable 


TRACT-ASSIGNMENT (TRACT1 ) 
TRACT -ASSIGNMENT (TRACT2 ) 
TRACT- ASS I GNMENT (TRACT3 ) 
TRACT-ASSIGNMENT (TRACT4 ) 
TRACT-ASSIGNMENT(TRACT5) 
TRACT-ASSIGNMENT (TRACT6 ) 
TRACT-ASSIGNMENT(TRACT7 ) 
TRACT-ASSIGNMENT(TRACT8) 
TRACT- ASS IGNMENT (TRACT9 ) 
TRACT-ASS I GNMENT (TRACT1 0) 
SCH00L-CAPAC( JEFFERSON ) 
SCHOOL-CAPAC (WASHINGTON ) 
SCHOOL-CAPAC (HAMILTON) 
WHITE-RATIO(JEFFERSON) 
WHITE-RATI0( WASHINGTON) 
WHITE-RATIO(HAMILTON) 
BLACK-RATIO( JEFFERSON) 
BLACK-RATIO (WASHINGTON) 
BLACK-RATIOCHAMILTON) 


-0.140000000+01 
-0.27999998D+01 
-0.899999920+00 
-0.13000000D+01 
-0.400000010+00 
-0 . 60000002D+00 
-0.140000000+01 
-0.1 7000001 D+01 
-0.120000000+01 
-0.150000010+01 
0.1 999999 3D+00 
O.OOOOOOOOD+OO 
0. 500000060+00 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
O.OOOOOOOOD+OO 
0.000000000+00 


Figure  11.  GXMP  Display  of  School  Rezoning  Model  Solution 
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or  "Demand (3 ,4}"  are  just  not  descriptive  enough  in  most  cases.  Furthermore, 
users  are  often  required  to  enumerate  each  name  as  input  which  can  be  extremely 
tedious  for  large  problems.  Imagine  having  to  input  "DEMAND(i ,j)"  for  i  and 
j  equal  to  100. 

The  QXMP  subverts  this  problem  largely  through  the  power  of  its  modeling 
language.  The  user  need  only  enter  each  parameter  name  in  the  model  once, 
generically  as  It  were.  Thus,  "DEMAND(i,j)"  is  the  only  GXMP  entry  necessary 
for  a  parameter  representing  the  demand  from  city  j  for  a  product  at  city  i. 
After  the  model  with  this  parameter  is  formulated  and  solved,  the  solution 
(assuming  DEMAND(1,j)  is  a  decision  variable)  is  displayed  with  index  values 
substituted  for  i  and  j,  e.g.: 


DEMAND(OALLAS, SEATTLE) 

1124. 

DEMAND (DALLAS, LA) 

3962. 

DEMAND (TUCSON, SEATTLE) 

836. 

The  decision  variables  are  fully  documented  at  the  back  end  with  this  convention 
while  requiring  a  minimum  of  input  at  the  front  end.  The  user  supplies  only 
the  names  (15  characters  or  less)  for  each  "generic"  variable.  The  same  conven¬ 
tion  Is  employed  in  prompting  the  user  for  parameter  data  values  once  the  param¬ 
eter  names  have  been  defined.  Thus,  usage  Is  consistent  throughout  the  process 
from  model  formulation  to  model  solution. 

Another  user-friendly  feature  of  this  approach  is  the  ability  to  focus 
on  a  subset  of  the  solution.  This  can  be  done  in  the  solution  reporter  by 
specifying  explicitly  which  variables  the  user  wants  to  see.  Thus,  one  can 
specify  STUDENTS (TRACTS .WASHINGTON)  to  see  only  that  value,  or  more  useful, 
specify  STU0ENTS(*, WASHINGTON)  to  see  the  number  of  students  from  each  tract 
who  are  to  be  bused  to  the  Washington  school.  The  *  "wild  card"  character 
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provides  a  powerful  feature  for  looking  at  only  the  parts  of  the  solution  which 
a  user  Is  particularly  interested  in.  The  advantages  of  this  approach  over 
wading  through  a  massive  printout  to  find  a  limited  set  of  solution  variables 
are  readily  apparent*  especially  for  large  models  with  many  decision  variables. 

Notice  that  in  addition  to  fully  identifying  the  decision  variables  in 
the  solution  basis,  GXMP  also  provides  an  equivalent  capability  for  the  dual 
variables.  This  is  accomplished  by  assigning  each  equation  an  equation  name  in 
addition  to  a  unique  numeric  identification.  (Note:  GXMP  has  not  yet  been 
modified  to  display  these  names  which  is  why  they  do  not  appear  in  Figure  9.) 
Thus  equation  CONSTR  10  is  TRACT-ASSIGNMENT,  CONSTR  20  is  SCH00L-CAPAC  and  so 
forth.  Thus  the  dual  variables  can  be  associated  with  their  corresponding 
equation  appropriately  Indexed  as  in  Figure  11.  This  feature  helps  document 
the  equations  and  Improves  the  readability  of  the  solution  report. 

5.  CONCLUSIONS  AND  FURTHER  RESEARCH 

The  development  of  the  GXMP  system  has  been  scheduled  in  three  phases. 
This  paper  has  discussed  the  results  of  the  first  phase  which  is  the  design 
and  Implementation  of  a  model  management  system  for  LP  models.  The  current 
version  of  GXMP  Is  essentially  a  user-friendly  top  end  for  LP  software  with 
built-in  capabilities  for  model  management.  Further  work  is  necessary  to  make 
fuller  use  of  these  features. 

The  second  phase  is  concerned  with  extending  the  knowledge-based  nature 
of  the  system.  Although  the  apparatus  for  a  knowledge-based  modeling  system 
is  already  In  place,  many  theoretical  issues  remain  to  be  studied  before  imple¬ 
mentation  can  occur.  In  particular,  the  following  areas  need  to  be  resolved: 

1.  What  kinds  of  knowledge  to  represent  about  models. 

2.  How  to  represent  this  knowledge  (the  model  abstraction  needs  to  be 

defined  more  carefully). 
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3.  What  kind  of  inferencing  and  pattern-matching  technique(s)  to  use 
with  regard  to  models. 

The  third  phase  of  GXMP  development  Is  to  extend  the  system  to  a  general¬ 
ized  model  management  system  (GMMS).  This  Involves  Incorporating  other  classes 
of  models  (e.g.:  simultaneous  equation  estimation,  discrete  event  simulation, 
etc.)  into  the  knowledge-based  framework.  This  will  test  the  versatility  of 
the  model  abstraction  concept  and  may  entail  extensions  to  the  modeling  language 
and  compiler.  Another  Important  issue  to  be  addressed  in  this  stage  is  the 
development  of  a  technique  for  linking  models  to  form  composite  models  as  well 
as  the  inverse  operation  of  decomposing  models  into  simpler  components  which 
can  then  be  relinked  after  solution. 
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